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INTRODUCTION 

This document describes the functions and proposed iapleaientatlon 
of a scheduler for Hultlcs which will allow more flexible 
administrative control of the allocation of the cpu time resource 
to system users and groups of users- 
It Is not an ob) active of this jwoposal to attempt to achieve 
greater throughput In any numerical sense. However, it is an 
explicit oblective that throughput of ] obs deemed most valuable 
by a system administrator will be increased. To that extent, the 
value of Multics as a computer utility is enhanced. Of course, 
Bverf effort mH i be made to ensure the efficiency of the design 
and implementation of the priority scheduler. 

THE PR08LEH 

Currently* the Answering Service provides a mechanism (load 
control) for classifying users Into groups, and giving each group 
a specified share of the system (by limiting the number of users 
from each group that may be logged in concurrently). 

However, except for the setting of the per-process parameter, 
tlmax, no control over the rate of consumption of cpu resources 
by any user or group of users is provided. (Briefly stated, 
there is a parameter, ti, associated with each process, which is 
roughly proportional to the amount of cpu time used by the 
process since it last Interacted. If the value of ti for a 
process ever exceeds timax, it is set to tlmax. The process with 
the lowest value of ti is always selected for eligibility.) In 
practice, the considerable advantage given to a process by a 
lower-than-normal value of tlmax has prevented all processes but 
the Initializer (and sometimes Backup) from being given timax's 
lower than the default value. 

THE SOLUTION 

This HTB proposes that the scheduler allow the grouping of 
processes into work classes, and provide each work class with a 
guaranteed percentage of available cpu time. Conceptually, each 
work class will be assigned a virtual processor of 

liultics Project internal working documentation. Not to be 
reproduced or distributed outside the Hultlcs Prolect. 
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administratively defined computational poMer, available to 
members of the appropriate work class on demand. Any cpu time 
r%Q* naaMaHt ny a uQrk c ! ass Mill be fflade available to other HorK 
classes* and cannot be reclaimed at a later time. In this 
respect each virtual processor is IlKe a real processori time 
unused is time tost forever. 

In its idealized form, the scheduler proposed here provides each 
work class with a specified computational power on an 
instantaneous basis. The Idealized scheduler has a time constant 
(or Integrating tlmel approaching zero seconds. The service and 
function provided by the idealized scheduler are known constants, 
not sublect to being bent out of shape by previous transients in 
per-workciass loads. 

The actual scheduler will for reasons of system efficiency, 
scheduler efficiency and response, necessarily have a time 
constant on the order of several seconds. As an example, 
consider the time constant required to smoothly provide service 
to a work class which has been assigned 20 percent of a single 
CPU configuration and whose members are generally provided with 
an eligibility quantum of 2 seconds. If the scheduler functions 
correctly, some process It% the work class will be given a two 
virtual second quantum every 10 virtual seconds, or approximately 
every 20 real seconds. This Implies that in some way the 
scheduler must be Integrating over the past 20 real seconds for 
such a work class. Averaging over a considerably shorter period 
would require significantly shorter quanta and result in 
Increased scheduler and paging overhead. Averaging over longer 
periods of time moves away from the idealized scheduler and 
toward a scheduler whose behavior is more dependent than 
necessary on the past history of the system. 

The ability to limit the number of processes in each work class 
is clearly desirable. If not an absolute necessity, and the 
ability to assign each process to a specific work class is 
obviously needed. 

To have two separate and independently-functioning mechanisms for 
classifying users into groups and limiting the number from each 
group that may be logged in concurrently is at best unnecessary, 
and at worst, confusing and full of hidden problems. 

Therefore, there must be a close relationship between work 
classes and load control groups, and a single algorithm must be 
used to determine a process's membership in both classifications. 
For example, there could either be a one-to-one correspondence 
between work classes and load control groups, or else the work 
class of a process could be a function of its load control group, 
with possibly more than one load control group belonging to one 
work class. Me have chosen the latter, more general, 
alternative. 
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It Mill be possible for the systen administrator to specify the 
number of work classes (a fi»lt of 16 hIM be Inposed by the 
scheduler)! and the guaranteed percentage of each work class* 

The administrator will be able to define the aembershio of each 
work class. It Mill be possible to define such work classes ast 
all 10 dae«ons» the Backup daemon» all users on a certain 
prolect* or one individual user. In each of those groupingst it 
will be possible to assign absentee and Interactive processes 
either to the same or to different work classes. 

The set of work class parameters^ and the membership of each will 
be able to be changed automatically Cat each shift change) and 
manually (by the system administrator, who may install a new 
table at any time). Thus« the work classes of existing processes 
can change. 

HARDCORE SCHEDULER 



The new scheduler will maintain an eligible queue consisting of 

eligible processes only and will manage 16 ready queuest one for 

each work class. Each ready queue will be managed Just as the 

non-eligible portion of the current ready queue is managed --- 
that is the queues will each be Internally sorted by ti values 

and favor the most interactive users within the work class. The 

current method of maintaining a ready queue is chosen for the new 
scheduler for three reasonst 



1. It Is response orientedt and in fact has been proven to 
provide the mlniaum mean respose time. 

2. If such 3 queue consists of processes ail with ti - timax, 
the the queue is largely run as a pushdown stack. This 
leads to very desirable paging behavior in that the most 
recently run process (the process most likely to have its 
working set still in core or on the paging device) will 
often be the next process to be run. 

3. Use of already existing code will simplify the 
Implementation effort required. 

To contain information pertaining to each work class, tc_data 
will contain 16 work_ciass_tat>le_entries (HCTE's). Each "mcTE 
will contain a thread-word for accessing the members of the work 
class which are ready* and all parameters and metering data 
relating to the work class. This will include the total amount 
of virtual CPU time used by the work class, the total number of 
times eligibility was granted to a member, the fraction of 
virtual CPU time which the work class is to receive, and the 
response time seen by its members. 
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The actual algorithn used to enforce the proper sharing of the 
CPU resource will be as follows. Imagine the existance of a 

-...A ..ii..*..^! »l«t>>w uKtf-K I ni-r-ononi-c a<s ulftual tine iS USed bV 

non-idle processes. Imagine also that each work class has a 
store of credits (in units of microseconds) which is continually 
growing at a ''ate proportional to the speed of the virtual clocK 
multiplied by the fraction of cpu resources which the worh class 
is to receive. Suppose further that the store of credits for the 
work class Is decremented as members actually consume virtual cpu 
time. Clearly It is undesirable to allow credits to build up 
indefinitely for a work class with no processes ready, so a 
maximum value is set on the number of credits which can be 
accumulated. In addition the value is restricted from ever 
becoming negative. The algorithm for choslng the next work class 
from which to choose a process to which to award eligibility may 
then be as simple as choosing that work class which has 
accumulated the maximum number of credits. 

A worthwhile refinement would be to choose the work class for 
which the ratio of the number of credits to the quantum to be 
awarded (le. to the top member of the given ready queue) is a 
maximum. This tends to favor the prompt scheduling of the most 
Interactive users across all work classes. It does not cause 
non-interactive work classes to fall far behind since eventually 
the interactive work classes choke off. This is because they are 
temporarily using credits faster than they are gaining them, and 

will eventually have a ratio which is arbitrarily low and not 

be chosen. 

It follows that the maximum build up of credits to be allowed 
must be greater than the maximum quantum allowed. It should 
probably be at least double that amount. 

The computation required for such an algorithm will amount to 
about 300 microseconds per eligibility granted, less if fewer 
than 16 work classes are defined. If eligibility is awarded lO 
times per second (a high figure) on a one cpu configuration, the 
loss in system throughput may be about .3S:. This is somewhat 
reduced by the fact that all sorting operations into the ready 
queue will be replaced by sorts into shorter queues. 

HARDCORE INTERFACE 

The Interfaces to the hardcore scheduler will be the following* 
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not be heavily used It will call Hlre_proc$i«ire_iie rather 
than being pernanenti/ wired. It will be Illegal to 
undefine a work class that currently has processes In It. 
If that is atteaptedf the processld and work class number of 
one of the "of fending" processes will be returned, in order 
that appropriate action can be taken. 

2. A gate to reassign OT%e existing process to a different work 
class. It will refuse to change the work class if the new 
one is not defined. It is tentatively called 
hphcs_ts8t_process_work_class. The target of this gate will 
be pxss$set_work_class. 

3. An additional para«eter in the create_info structure passed 
to hphcs_$create_procJ the initial work class. It will be 
illegal to specify a work class that is not defined. It 
will be necessary for act_proc, the target of 
hohcs_$create_proc» to call pxssSset_work_class, to insure 
that the work class being assigned to the new process 
currently exists* 

A prinitive to sinultaneousty redefine the work classes and 
reset the work class of each process is neither required by 
logical considerations nor Justified by efficiency 
considerations. Furtheraore such a primitive would not be able 
to handle an arbitrarily large number of |K*ocesses. 

In order to redefine the work classes in the general case« It 
will be necessary first to define a transitional set of work 
classes and percentages (including both old and new work 
classes)* then to reset the work class of each process to the 
new value* and finally to define the new set of work classes. A 
procedure to do this will be implemented in the answering 
service. 

SUHMARY OF CURRENT LOAD CONTROL SOFTWARE 

Since work class membership wilt be a function of load control 
group membership* work class definitions will be stored in the 
HGT* and the imp lamentation of the ^^swerlng service and 
administrator interface to the priority scheduler will consist 
mainly of modifications to the current load control software* a 
summary of that software, as it now exists, is presented here- 

Load control group membership is specified In the SAT entry for 
each project. In addition* each project's SAT entry contains an 
absolute max user figure for that project that is enforced 
independently of the load control groap limits. 

Absentee and daemon processes are not subject to load control. 
They are always logged in on request. They are assigned to the 
load control group corresponding to their projects, but their 
group membership is ignored by everyone. 
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Load control groups are defined In the iBaster_group_table (MGT)t 
which Is a binary table maintained by an editor (ed.ngt), and Is 
not subject to rne Ansxan ois»«-AiJ» »<•«• \t.f .■..*# , — ,^ w,....-.,.- 
limit parameters for each groupt set by the system administrator, 
and it is also used to hold current load figures for each group, 
during a session. 

The group limits are defined in units of user weight, rather than 
number of users. tThere are, however, limits in units of users, 
for the system as a whole, and for each project.! By default, 
each user has a weight of 10, so max_unlts Is ten times 
max users- Height is a function of the process overseer, and is 
determined by an array of weights kept in the SAT header. 

There are two sets of limit parameters per group, one used to 
compute primary_maK_units, the other, to compute 
absolute max.unlts. Each set contains three parameters! a 
constant~( which may be zero), and a numerator and denominator of 
a fraction. The formula for absolute_max_unlts for a group 1st 

absolute max_unlts = absolute_constant ♦ 

< aval I abTe_max_uni ts»absol ut e_numerator> /abso I ute_denomlnator 

where aval lable_max_unlts is the system_max_unlts less the units 
used by the absentee~and daemcm processes who are not subject to 
load control. The formula for primary^max_unlts Is the same, but 
using prlmary^constant, primary^numerator, and 
primary .denominator. 

These calculations are performed for all groups each time a user 
attempts to log In, so changes to units used by absentee or 
daemons, changes to system_max_unlts, or changes In the HGT made 
by the system administrator are all taKen Into account 
Immediately. 

The system_max_unlts figure Is either* 

1. taKen from the SAT header, for a special session, or 

2. set by the operator, using the maxu command. In which case 
automatic maxunits setting Is turned off, or 

3. set autoiatically at each shift change and whenever the maxu 
auto command is given by the operator. The automatic setting 
looks up the current shift and configuration in the config 
array in Instal latlon_parms, and chooses the corresponding 

<1) The Install discipline Is a method used for installing 
certain critical tables, whereby the Answering Service installs 
the table, when requested by a system or project administrator, 
ensuring that the Answering Service will not attempt to reference 
the table while It Is being updated. 
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values fori system_iBax_unlts» niax_absentee_userst 
■ax_absentee_queue« and response.hlgh and response.toM. (The 
latter tMO figures are used by fhe load leveler (when it is 
enabled by the raaxu level cofflmand)* Mhich readjusts 
systeiB_«ax_units at every i5-«inute accounting update* to 
keep response between the high and Iom figures*} 

The load control decision is rather coaplex* Mhen special 
privileges like guaranteed login* the nobump attribute* and 
protection from preemption for a specified grace time are taken 
into account. But basically* if the systea is full (as measured 
by systeiB_«ax_units or syste«_raax_users) then someone must be 
bumped or else the user is refused login. If the system is not 
full, but the group or the project is full <as measured by the 
group's absolJte_«ax_units or the project's max_users), then 
someone in the group or project must be bumped* or else the user 
is refused login. If the group's primary_max_units are all 
allocated but its absolute_»ax_units are not* then the user is 
logged in as a secondary user* subject to preemption. Secondary 
users (in any group} are the first to be bumped (oldest first} 
when some primary user wants to log in* fot toMed by primary users 
(in the same group) Mhose grace ti«e has expired* folloMed by 
practically anybody* Mhen a user with the guaranteed login 
attribute is trying to log in. 

The load control group membership of a process never changes* but 
both the proportion of the avai lable_»ax_units that each group 
gets* and the number itself* can vary Mith the 
avaHable_»aK_units (which varies with shift* configuration, and 
absentee and daemon load)* because of the max_units formula 
described above. 

NEW ANSWERING SERVICE ANO ADMINISTRATOR INTERFACE 

The HGT will be reformatted to hold work class definitions as 
well as load control group definitions. Since there will be a 
maximum of 16 work classes* but there is currently no restriction 
on the number of load control groups* the new MGT will consist of 
a header, followed by a fixed- length array of i& work class 
definitions, followed by a variab I e** length array of load control 
group definitions. The header and the load control group 
definitions wilt remain essentially unchanged* except that each 
load control group definition will contain two additional 
8-element arrays* specifying the work classes to which 
interactive and absentee users in that load control group belong 
on each shift. 

One or more load control groups can belong to each work class. 
The max.users and max_units figures for each work class will be 
the SUB of the corresponding figures for the load control groups 
that make up the work class. The work class maxima will not 
actually be computed and stored anywhere by the answering 
service* but they will be displayed by ed_mgt to assist the 
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system administrator in assigning reasonably consistent 
percentages to the work classes and max user and unit figures to 
the load control grouas- The normal operation of load control* 
as described abovet Mill limit the number of processes in each 
Mork class. 

The ed.mgt command Mill be modified to be able to store and 
modify the Mork class parameterst to verify, on request, the 
correctness, reasonableness, and consistency of work class 
parameters and the corresponding load control group definitions, 
and to print work class definitions and a cross reference showing 
the correspondence between load control groups and work classes* 
The changes to ed_mgt are described in detail in a later section. 

The install command will be modified (and a new procedure, 
up_mgt_, will be written* so that the M6T can be installed while 
the system is up and users are logged in. up_mgt_ will have to, 
in general* reset the work class of all existing processes to the 
work class specified in the newly-installed HGT. 

The answer table (and daemon and absentee user tables), and the 
create_lnfo structure passed to hphcs_$create_proc, will have a 
new variable, work_class, added. 

Ioad_ctl_$load_ct l.inlt will call hphcs_$def lne_work_classes, to 
define the work classes to be used by the scheduler, during 
answering service initialization. (This call must be made before 
the daemons are fogged in.) 

load.ctl_Jset_maxunits, which is called at eact> shift change (as 
well as during the second half of answering service 
initialization, and whenever the operator command "maxu auto" is 
given) will redefine the work classes, as specifed for the 
current shift in the HGT, and will reset the work class of each 
existing process as required. 

Since the function of redefining the current work classes and 
resetting the work classes of all existing processes must be 
performed both at shift change and whenever a new MGT is 
Installed, it will be implemented as a separate procedure, called 
In both situations. 

To support the assignment of work classes on the basis of person 
as well as project, the SAT and POT, and the procedures which 
compile, edit, and install them, will be modified to allow a load 
control group to be specified for an individual user rather than 
}ust for a whole project. 

A new attribute, igroup (individual group), will be created. Hhen 
that attribute is on in the SAT entry for a project, it permits 
the load control group for users on that project to be specified 
in the POT entry for any user on that project. (If that attribute 
is not on in the SAT entry, then all users on the project will 
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continue to belong to the load control group specified in the 
project's SAT entry.) Mhen the igroup attribute is on in the PDT 
entry for an individual user, it indicates that a load control 
group is specified in that user's POT entry. (If igroup is not 
on in a user's POT entry, that user Mill continue to be a menber 
of the load control group specified in the project's SAT entry. 1 
The nane of the individual user's load control group h1 li be 
stored in a presently unused pad field in the POT entry. This, 
plus the use of igroup in the PDT entry as a positive indication 
that a group Is specified, wilt ailot* this change to be installed 
without requiring that any existing POT's be reformatted or 
reinstalled. 

'g-ctl_ Mill be nodlfled to assign a load control group on the 
basis of person as well as project, as described above. 

load_ctl_ will be modified to use the load control group of each 
process to assign it to the work class specified in the MGT for 
absentee or interactive users in that group, on the current 
shift. (Oaenon processes will be treated as interactive, for the 
purpose of work class assignaent.* The assigned work class will 
be stored in the answer table (or absentee or daemon user table) 
entry for the process. 

cpg_ Mill copy the work class fraa the answer table entry into 
the create_info structure, before cal I Ing hphcs_lcreate_proc. 

INSTALLATION PROCEDURE 

The hardcore system containing the priority scheduler, and the 
answering service containing the above modifications, can be 
installed in either order. If hphcs_$deflne_work_classes is not 
called, a single work class (work class D wilt exist by default, 
and will have a percentage of lOOZ. The version number of the 
create Info structure will allow act.proc Cthe ring zero 
procedure called via hphcs_tcreate_proc) to determine if the new 
version, containing the work class, has been passed. If the old 
version of create_lnfo is used, act_proc h1 1 1 assign processes to 
work class l by default. This allows the hardcore system to be 
Installed first. 

The new answering service will check for the old format MGT, and 
If it is found, none of the new gates will be called, and every 
process will be assigned to work class l. Independent of their 
load control group membership. Further, a switch in the 
reformatted MST, sattable by ed_mgt, will allow this mode of 
operation to be specified by the system administrator after the 
MGT is reformatted. Finally, a check for the existence of 
hphcs_$deflne_work_cl asses will be made during answering service 
initialization, and if it is not present, the old mode of 
operation will be used. This will make the new answering service 
compatible with older system tapes. It will also cause the 
system to run as it does now, with only one work class, when both 
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the ne« answer ing service and the net. hardcore system are 

installed. The new scheduler m1 1 1 not be turned on until the M5T 

^ .. ^^^^ -.^ «h.^ <-uc!>-t'aMi aHn tnt etr^tor exollcltly enables 

is rei or' ma i i bu» cmv* inw ^7^.»,— ——-.-..---■-•- 
it. 

The s/stem aduinistratop will» of course, be informed of all this 
in release documentation. The first time he uses the new e<i-™9t, 
it will recognize the old format HGT, reformat it automatically, 
define a single work class (work class l» with a percentage of 
lOOZ, make all load control groups members of it, and then invite 
the system administrator to define more work classes and reassign 
the load control groups to them- It will not be required that 
the administrator do so, but ed^mgt will keep reminding him, 
every time he uses it, until he does. 

Since the MGT will now be subject to the install discipline, the 
reformatted copy can not be put back in >scl. Hhen the w 
request is given, the reformatted MGT (named MGT. mgtl will be 
written in the working directory of the administrator (which 
should be >udd>sa>admin) . The administrator wi 1 1 be told about 
this by ed mgt. Except for the instance when the MGT is 
reforroatted7 the edited HGT will be written back into the input 
MGT, as is done now. However, the system administrator will not 
be editing the >scl copy any more. As a convenience, atter 
writing the edited copy back into the original, ed.mgt will 
always ask "Install?", and if the answer is yes, it will Invoke 
the install command. The administrator will of course be able to 
invoke it directly. 

The installation procedures described above will make testing and 
Initial installation of the system very convenient, and it will 
also allow the system administrator at each customer site to turn 
on the priority scheduler at his convenience. Instead of forcing 
him to define some (possibly Ill-considered) work classes. Just 
to get the new system release to run. 

CHANGES TO ed_mgt 

Summary of Current ed_mgt 

The following summary describes only those features that are 
being changed. The HGT, as seen by a user of ed_mgt, is an array 
of load control group definitions. The find (f> request positions 
the current pointer to the specified group. The next (n», top 
(tJ, and - (minus sign* requests move the current pointer forward 
or backward in the array. The change (c) request changes 
parameters of the current group. The print (p) request prints all 
information about the current group. The pall (pa, P*) request 
prints all information about all groups. Only the find and change 
requests take arguments. Their formats arei 

find <group name> 

change <code> <new value> t<code> <new value> ...1 ♦ 
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where <code> is the naiae of the paraaeter to be changed. Typing 
these requests Mithout arguaents causes ed_»gt to prompt the user 
for theiB* The change request puts ed_iiigt into the change 
subcofflnandt in which <code> <neM vaiue> pairs are accepted. The 
asterisk at the end of the line exits from the change subcommand 
and returns to ed_mgt request level. 

Summary of New Features 



The find request 
consisting of one 
corresponding work 



will be modified so that a <group name> 
of the integers 1 through 16 will refer to the 
class. 



The next» top, and - requests will be modified to print the name 
and type of the entry being pointed at after the pointer is 
moved. 

The change request will be modified so that the set of codes 
accepted will be different, depending on which type of entry 
(work class or load control group) the current pointer is 
pointing at. New codes and other arguments will be added, to 
allow parameters of work classes, and the work class membership 
of load control groups, to be edited. 

A new request, global_change (gc), will be added, to allow the 
same (set of} changeCs} to be made to all morH classes or to all 
load control groups. 

A new request, verify (v>, will be added, to request that ed_mgt 
check all the work-class-related parameters in the edited H6T, 
and report any errors or warnings that would be received if the 
MGT were to be installed. 

The print and pall requests will be changed to print the new 
parameters, and the pal ( request wi 1 1 take arguments, requesting 
that all work classes, or all load control groups, or both, be 
printed, or that a cross reference of work classes and load 
control groups be printed. 

Detailed Oescriotions of New Features 

Two new formats for the change request will be addedt 

change <code> [<shift specif ication>] <one or more values> 

change <code> C<shift speol <interactivet absentee> <value(s)> 

The first is used when editing work class parameters; the second, 
while changing the work class membership of a toad control group. 
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The fol lowing new <code>'s can be used in the above requests* 

absentee Cabs) 
defined fdef) 
wopk^class («cl 

The first three are used with the first form of the change 
requestf to edit work class paraneters- The fourth is used with 
the second forwf to change the work class membership of a load 
control group. 

The format of the <shift specif ication> is the word "shift" 
followed by a shift number or a range of shift numbers (two 
numbers separated by a hyphen, the second greater than the 
first)! 

shift <number>l <number>-<number> 

The shift specification is optional. If it is omitted, the 
default is a function of how many values are supplied. If one 
value is supplied* it is assigned to all 8 shifts. If a list of 
values is supplied, they are assigned to shifts 0* 1, •••» 
respectively, and shifts for which values are not supplied are 
not changed. 




<interact ivel absentee> can be» 

interactive (int) 
absentee (abs) 

This argument Is used when setting the work class of a load 
control group. Separate work classes may be specified for 
interactive and absentee processes in the load control group, on 
each shift. If this argument is omitted, but the work class 
valueCs) are given, the default is interactive. 

The work class parameters "defined" and "absentee" can have 
values of "off" or "on" (or "0" or "1"). They are per-shift 
switches, that indicate respectively, whether the work class is 
defined on the given shift, and whether absentee processes are 
permitted in it on that shift. 



HTB-193 Page 13 

The foraat of the globai_change request Milt bet 

gc <type> <argunients acceptable to the change request> 

Mhere <type> can bet 

load_cofttPol_gro«p Cleg) 
Mork.class (mc) 

The effect of this coaaand will be to nake each change (specified 
by a change subconmand) to all entries of the specified type. 

The fornat of the pait (print alll request Mill bet 

ball <type> 

Mhere <type> can bet 

load^confrof _group (Icgl 
worK_class (»c) 
cross_reference (cref* xrefl 

If <type> is oiiittedf the default will be to print all three sets 
of information* 

Exanplesi 

change % 10 • 

change % shift lO lO iO lO lO 10 lO lO . 

change pet shift 0-7 10 • 

The above are equivalent ways of assigning 10% to the current 
Mork class on ail shifts* 

change Z shift i 50 X shift Z-h 30 . 

The above request is equivalent to the following two requestsi 

change X shift 1 50 • 
change X shift 2-4 30 . 

c wc int shift 1 3 wc shift 2-4 int 2 wc abs 1 * 

The above sets the interactive work class of the current load 
control group to 3 on shift l and to 2 on shifts 2-*»t and the 
absentee work class on all 8 shifts to i. Notice that the shift 
specification and the interactivelabsentee indicator nay appear 
in either order* 

gc wc defined shift off defined shift 5-7 off . 

The above will set all work classes to undefined except on shifts 
1-4. This would be useful at an installation where only shifts 
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l-i» were In uset to simplify the output of the print and palf 
connandSf since ihfornation about undefined shifts is not 

Mote that* in the examples* a period is used to terminate the 
change request lines Instead of an asterisk. In the new ed_mgt» a 
period Hill be accepted for that function* in addition to an 
asterisk* for compatibility with other Multics editors. 

The examples show all required arguments supplied on a single 
ine. ed^mgt Mill prompt for missing values. The example above* 
n which the percents for shifts 1 and Z'k were changed* would 
ook like this if the user typed only what was requested (! 
ndicates prompting messages) I 

type* 

change 

code! 

% 

shift! 

1 
value(s) t 

50 

codet 
X 
shifts 

valuei 

30 

codet 

• 

typei 



